The Internet is a global system of interconnected computers and computer networks that use a standard Internet protocol suite (e.g., the Transmission Control Protocol (TCP) and Internet Protocol (IP)) to communicate with each other. An Internet Protocol address (IP address) is a numerical label assigned to each device (e.g., computer, printer) participating in a computer network that uses the Internet Protocol for communication. The Internet Assigned Numbers Authority (IANA) manages the IP address space allocations globally and delegates five regional Internet registries (RIRs) to allocate IP address blocks to local Internet registries, such as, Internet service providers (ISPs), and other entities. Traditionally, an IP address has been defined as a 32-bit number, and a conventional system using 32-bit IP addresses is known to follow an IP version 4 (IPv4) protocol. However, due to the explosion of the number of devices connected to the Internet in the past years, the 32-bit IP address space has been depleted and several mechanisms are in place to combat this problem.
Rather than assign unique IP addresses to each device connected to the Internet, private networks consisting of two or more computers or devices have been developed, where a public face of the private network can be assigned a public or global IP address, whereas the devices within the private network need not have uniquely assigned IP addresses in the global sense. In other words, the private networks can manage any suitable addressing mechanism for devices within the network, and the private addresses for the devices are not routed directly on to the Internet. For example, devices within the private network can have private addresses that need not be coordinated with a global IP address registry or ISP, but these devices can communicate with one another, within the private network, through TCP/IP protocol. However the devices within the private network may often need to be protected for security concerns and these devices may be prevented from directly connecting to the Internet. The private addresses within a private network are not made globally visible through the Internet.
A network address translator (NAT) is a well known device or mechanism used in interfaces between private networks and the Internet. NATs can be used to initiate connections from within a private network to the Internet, but they hide the private network addresses behind public IP addresses. For example, a NAT performs modifications to addresses associated with data traversing the private network/global Internet boundary and maps the IP address from the private IP address to public IP address and vice versa. This enables communication between the devices within the private network and the Internet, while masking or hiding the private IP addresses.
In practice, the devices typically communicate with the Internet using a user datagram protocol (UDP). UDP uses a simple transmission model with no handshaking dialogues. The devices or computer applications can send “datagrams” or packets to other hosts on the private or public IP networks without requiring prior communications to set up special transmission channels or data paths. For outbound packets sent from the devices within the private network to the Internet, the NAT allocates temporary port numbers, wherein the temporary port numbers are correspondingly mapped to the devices which send the outbound packets. The NAT retains the mapping for a predetermined period of time, which is also known as a duration of flow. When inbound packets are received from the Internet, the inbound packets include the allocated port numbers to identify the destination device within the private network. The NAT uses the mapping to forward the inbound packets to the device in the private network that corresponds to the port number included in the inbound packet. In this manner, the private addresses of the devices within the private network are hidden from the Internet by means of the NAT.
The NAT can provide an effective solution for typical client-server communications, such as, browsing the worldwide web or accessing email, since it is the client or host (e.g., a device within the private network) that would initiate such a communication with an Internet server outside the private network, and the connection through the NAT would not need to be maintained for a long time. However, for communication between two clients or hosts within the private network, also known as peer-to-peer communication (e.g., a voice over IP or “VoIP” communication) a conventional NAT implementation would give rise to several problems.
In peer-to-peer communications such as, VoIP, the goal is to have audio and/or video data or packets flow directly between the two peers or clients. Such direct flows in peer-to-peer communications would eliminate the need for relaying agents, which is desirable because relaying agents add cost, consume bandwidth and introduce latency. In order to perform a VoIP communication, each client would need to inform its address to the other client by sending the respective addresses over the VoIP signaling path. When a NAT is present, and a first client attempts to send its private address to a second client for a VoIP communication with the second client, the NAT would assign a first port number to the first client for the outbound packet containing the first client's private address. When the second client receives the packet, obtains the first client's private address and attempts to send data (audio/video) back to the first client's private address, this would not be successful, because the NAT would only recognize the first port number, not the first client's private address, for inbound packets to the first client.
Some NATs can support a so called hair-pin feature, whereby the NAT can forward packets from the first client to the second client when both clients are within the same private network. When hair-pinning is supported, the NAT can detect that the public IP address destination of the outbound packet from the first client is a mapped IP address that was created for the second client by the NAT. Thus, the NAT is able to use hair-pinning to forward packets correctly in order to support peer-to-peer communication between the two clients when they are both located within the same NAT's private network. While this is a desirable feature, it is not commonly implemented by NATs, particularly in commercial deployments. For example, in a coffee shop or other commercial establishments which feature WiFi access to its customers, a commercial NAT may be deployed for the establishment's private network. Allowing or implementing hair-pinning would allow random or unauthorized users of the private network to discover other users or user devices using hair-pinning. This is undesirable from a privacy and security perspective. Therefore, hair-pinning is not a commonly supported feature, particularly in commercial settings.
When hair-pinning is not an option, a traditional approach for NAT traversal involves a session traversal utilities for NAT (STUN). STUN offers a mechanism by which the first client can discover the presence of the NAT and also obtain a public IP address and port number of the first client that were mapped by the NAT. STUN requires assistance from a third-party server called a STUN server which is located on the public side of the NAT. The first client can find out its public IP address and port by querying the STUN server, and then send this public IP address instead of its private address to the second client. The second client can also similarly discover and send its public IP address to the first client. The two clients can then send data packets to the respective other client's public IP address in order to perform the peer-to-peer communication, such as VoIP communication, with each other. This mechanism of NAT traversal using a STUN server is also known in the art as punching a hole in the NAT. However, traditional STUN based approaches are insufficient for all types of NATs. For example, they would fail for symmetric NATs and port restricted NATs.
A symmetric NAT is among the most challenging, when it comes to NAT traversal. A symmetric NAT allocates different mappings of the same client within the private network (e.g., the first client) for communications to the STUN server and communications with other external hosts such as Internet servers. Accordingly, the IP address and port that is obtained by the first client from the STUN server and passed on to the second client for peer-to-peer communication is rendered meaningless, because the IP address and port number from the STUN server are different from the IP address and port mapping that the NAT creates for the peer-to-peer communication. Thus, when the second client tries to send a packet to the STUN based IP address of the first client, the NAT would drop the packet. A symmetric NAT is commonly employed, for example in commercial settings (where hair-pinning support is typically missing), and thus, yet other solutions are commonly employed in this space.
A currently outdated method, namely, traversal using relay NAT (or the “old TURN”) involves a method of overcoming the shortcomings of STUN with regard to traversal of symmetric NATs. According to old TURN, STUN would be used to detect the NAT type, and when a symmetric NAT type is discovered, the old TURN would be used as a relay. However, this straightforward approach turned out to be unreliable, and a new TURN is now in place. The new TURN (or simply, “TURN,” hereafter) pertains to traversal using relay around NAT. The TURN protocol will be described with reference to FIG. 1 below.
In FIG. 1, a conventional communication system 100 is illustrated, wherein a TURN protocol is deployed. System 100 comprises TURN server 102, which is located on the public side of NAT 104. In one example, NAT 104 can be a symmetric NAT. In this case, first and second clients, peer-1 106 and peer-2 108 would be behind the same symmetric NAT, NAT 104. The symmetric NAT and STUN would not provide a path for the purported peer-to-peer communication between peer-1 106 and peer-2 108. TURN server 102 would provide such a path by acting as a relay. The requests for communication from the clients behind NAT 104 will be forwarded through NAT 104 to TURN server 102. TURN server 102 would then allocate, for example, a first TURN address for peer-1 106 when peer-1 106 contacts TURN server 102 to establish a peer-to-peer communication with peer-2 108. TURN server 102 would do the same for peer-2 108, in that TURN server 102 would create a second TURN address for peer-2 108 when peer-2 108 contacts TURN server 102. TURN server 102 would act as a relay, and peer-1 106 and peer-2 108 would communicate through TURN server 102 using the first and second TURN addresses. Thus, the TURN protocol maintains security and also allows for communication to take place where symmetric NAT and traditional STUN may fail. However, the use of TURN servers is expensive, and the use of TURN servers for communication must be limited to a last resort, for example, when NAT and STUN would not work (e.g., in the case of the symmetric NAT situation).
Commercial TURN deployments typically have multiple TURN servers and a TURN virtual intranet platform (VIP) is used for balancing load among the multiple TURN servers.
An interactive connectivity establishment (ICE) protocol involves a NAT traversal technique that is used to find the best path for peer-to-peer communication between two clients which are behind the same NAT (ICE can also be employed when different NATs are involved). For example, referring back to FIG. 1, several paths for peer-to-peer communication can potentially exist between first and second clients, peer-1 106 and peer-2 108. A first possible path, path 110 is a direct path between the two clients, which may, for example, be through UDP sockets on the two clients. A Bluetooth communication between two Bluetooth enabled devices can constitute one example of a path similar to path 110. A second possible path, path 112 can be through NAT 104. More specifically, a socket can be created on NAT 104 that is mapped to each of the two clients, and in this case, NAT 104 is also known as a server reflexive candidate. The third possible path, path 114 is through a dedicated socket which is created on TURN server 102, where TURN server 102 is a relay candidate. ICE can determine, for example, based on performing a series of checks, the best option between paths 110-114, for example, based on the availabilities, specifications and requirements of system 100. The selected path will then be used for peer-to-peer communication between the two clients.
However, there remain situations where the conventional techniques known in the art are insufficient to establish peer-to-peer communication between two clients. For example, a symmetric NAT may further have a feature to enable wireless isolation, or in other words, the symmetric NAT would disallow wireless devices connected to the private network behind the symmetric NAT to access one another through the wireless network. This is again commonly seen, for example, in commercial establishments which offer WiFi or wireless network access to customers, to ensure that one user of the network cannot access another user's device in an unintended or unauthorized manner over the wireless network. Additionally, the typical case would involve a symmetric NAT, lack of support for hair-pinning, and a TURN VIP to balance load among multiple TURN servers. In this situation, conventional ICE implementations cannot provide or establish any means of peer-to-peer communication between two clients behind the symmetric NAT with wireless isolation enabled and without support for hair-pinning.
Accordingly, there is a need in the art for configurations which enable peer-to-peer communication between two clients behind a same symmetric NAT, where the symmetric NAT has wireless isolation enabled and no support for hair-pinning, and where a TURN VIP is configured to balance load amongst multiple TURN servers associated with the symmetric NAT.